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1.      INTRODUCTION 

A  group  in  the  Department   of  Computer  Science   at   the   University 

of  Illinois   is   currently  developing  a  general  purpose   simulation   and 

modeling  system.      Figure  1  shows    a  simplified  picture  of  the  system 
architecture . 


IBM  360/75 


44- 


DEC  PDP-8 


< — > 


TERMINAL 
CONTROL 


DISK 


USER 

GRAPHICS 

TERMINALS 


Figure  1.   Simplified  System  Architecture 


The  PDP-8  is   used  to  handle   all   drawing  functions,    and 
together  with  the   terminal   control  and  the   graphics  terminals,    allows 
a  user  to   draw  various   networks,    describe   their  functional   character- 
istics,   save   the  networks   for  later  use,   or  request  network   analysis. 
The  PDP-8  also  maintains   a  temporary  library  of  user  pictures   and 
networks   on  the   local   disk,  while   a  permanent  library  is   maintained  in 
the   360.      Extensive  network   analysis   is    also  performed  in  the    360. 

This  paper  describes   one   component   of  the  PDP-8  software 
system,   namely,   the   IR   (Information  Retrieval)    routines.      These 

routines   are   responsible   for: 

2  3 

1.  Performing  all  disk  operations  for  GLASP.  ' 

2.  Maintaining  the  local  library  on  the  disk. 

3.  Communicating  with  IR  in  the  360. 

Chapters  2  and  3  describe  the  functional  characteristics  of 
IR.   Appendix  A  contains  descriptions  of  the  internal  routines  in  IR, 
Appendix  B  describes  the  disk  layout  for  IR,  while  Appendix  C  describes 
the  Disk  Monitor  System  that  was  implemented  for  program  development  on 
the  PDP-8. 


2.   IR  FACILITIES 

A.  GLASP  Utilities 

Two  programs    are   contained  in   IR  to  perform  utility  operations 
for  GLASP. 

1.  BNKSWP 

This  program  is   used  to   save   and  restore   core  banks   0 

and  1  on  the    disk.      Eight   such   core   images    can  "be   saved, 

one   for  each   of  the   eight  terminals  that   GLASP  supports. 

Due   to  the  nature   of  the   disk,   two  banks   of   core  may  be 

transferred  in   one   disk  access.      Transfer  time    (including 

a  half  rotation   average   latency)    is   6l  ms .    in  either  direction, 

2 .  DSKGET 

A  collection  of  numbered  program  segments   is   maintained  on 
the   disk.      Each  program  segment   is   102U        words   long  and 
always   resides   at   3^000q  in  the  PDP-8.      GLASP  may   read  or 
write   any  particular  segment   by  calling  DSKGET.      Transfer 
time    (including  latency)    is   22.3  ms . 

B.  Library  System 

The  principle   function  of  IR  is   to  build  and  maintain  the   local 
library.      Programs   running  under  GLASP  will  need  facilities   for  saving 
and  retrieving  subpictures,   textual   data,    and  network   descriptions 
created  by  users   at   the   graphics  terminals.      IR  is   insensitive  to  the 
type   of   data,    and  merely  handles   blocks   of  PDP-8  words    along  with   a  name 
and  type   supplied  by  the    calling  program.      The   system  is    coded  in   such 
a  way   as  to   reduce   disk  references   and  to  reduce   latency  times  when  reading 
and  writing  files . 


Communi cations  between  programs  and  the  IR  library  is  through 
parameters  stored  in  the  console  vector,  and  via  ROUTX.   Specifically, 
a  program  describes  the  desired  operation  by  setting  up  words  5-12  in 
the  console  vector  of  the  current  console,  and  goes  to  ROUTX  with  a 
request  for  IR.   GLASP  keeps  track  of  all  system  resources  and  will 
transfer  control  to  IR  if  IR  is  not  busy.   A  location  in  core  points 
to  the  current  console  vector.   IR  will  service  the  request,  put  a 
return  code  indicating  the  degree  of  success  into  the  console  vector, 
and  return  to  the  program  via  GLASP  utility  OPDONE. 

The  console  vector  parameters  for  IR  are  shown  below: 


WORD  5: 
WORD  6: 
WORDS  7-9: 
WORD  10: 
WORD  11: 
WORD  12: 
The  FUNCTION  word  decodes  as: 
BIT  0: 

BIT  1: 


BIT  2: 


BIT  3: 


FUNCTION 

6  BIT  FILE  TYPE 

6  CHARACTER  FILE  NAME  (packed  ASCII) 

CORE  LOCATION  OF  DATA 

LENGTH  OF  FILE 

PROTECTION 

0  -  write 

1  -  read 

0  -  communicate  with  the  360 

where  appropriate 

1  -  no  360  communications 

0  -  save  file  locally 

1  -  do  not  save  locally 

0  -  if  a  file  to  be  written  already 

exists,  overlay  the  old  copy 

1  -  do  not  overlay  an  existing  file 


BIT  h:  0  -  no  action 

1  -  delete  the  named  file 
BITS  5-6:  core  bank  of  data 

BITS  7-11:  return  code  placed  here 

Common  combinations  of  the  function  bits  are  tabulated  below 
(X  is  a  "don't  care"). 


FUNCTION  BIT 


0      1     2      3     ^ 


Actions 


X  0  X  X  1 
X  1  X  X  1 
10      0X0 

10      1X0 

1  1  X  X  0 
0      0      0      0      0 

0      0      0      10 

0  0   10   0 

0  0   110 

0  10   0   0 

0  10   10 

0  110   0 

0  1110 

Figure  2 


Delete  locally  and  in  360. 
Delete  locally  only. 
Read  locally  or  from  360,  save 
a  copy  locally. 
Read  from  either  one,  do  not 
save  a  copy  locally. 
Read  locally  only. 
Write  a  copy  both  locally  and  in 
the  360,  overlay  if  necessary. 
Write  a  copy  in  both;  do  not 
overlay  an  existing  file. 
Write  in  360  only;  overlay  allowed. 
Write  in  360  only;  no  overlay  allowed. 
Write  locally  only,  overlay  allowed. 
Write  locally  only,  no  overlay  allowed. 
No  operation. 

No  operation — sets  a  return  code  of  3 
if  file  exists  locally. 
IR  Function  Table 


The   calling  program  sets  word  11   during  "writing  to  indicate 
the   length  of  the   file.      This   may  be  between  2   and  TT^lg  words .      For 
reading,   the  program  sets   the   amount   of  core   available  to  receive  the 
file.      If  the   file    does  not   fit,   IR  indicates   that  with   an   appropriate 
return   code.      In   any  case,   this  word  will   always  be   set  to  the   actual 
length   of  the   file. 


Return  codes  are 
0: 
1 
2 
3 
k 
5 
9 


operation   successful. 

file  to  be   read  does  not   fit   in   core. 

file   to  be   read  not   found. 

attempt  to  illegally  overlay   a  file. 

file   to  be    deleted  not   found  in   360. 

file   to  be   deleted  not   found  locally. 

file   to  be   deleted  not   found  anywhere, 


3.   LIBRARY  FUNCTIONAL  DESCRIPTION 

This  chapter  describes  the  inner  workings  of  the  various 
routines  that  comprise  the  library  system.   Appendix  A  contains  the 
names  and  calling  sequences  of  internal  routines  in  the  entire  system. 
A.   Directory 

The  library  directory  is  stored  on  the  disk  as  a  contiguous 
block  of  8192  words.   Each  directory  entry  is  8  words  long  and  contains 
the  following  information: 

WORD  1:  TYPE 

WORD  2:  USER  ID 

WORDS  3-5:  6  CHAR  FILE  NAME 

WORD  6:  FIRST  BLOCK  NUMBER  OF  FILE 

WORD  7:  FILE  LENGTH 

WORD  8:  PROTECTION 

The  TYRE  word  contains  the  user  file  type  in  bits  6-11.   Bits 
2-5  are  currently  unused.   Bits  0  and  1  decode  as  follows: 

BIT  0:  0  -  entry  is  not  currently  in  use 

1  -  entry  is  in  use 
BIT  1:  0  -  this  entry  has  never  been  used 

1  -  entry  has  had  a  name  in  it 
The  USER  ID  is  obtained  from  GLASP  and  uniquely  identifies  the  user  that 
created  the  file.   The  FILE  LENGTH  is  coded  as: 

BITS  0-k:  number  of  full  blocks 

BITS  5-H:  length  of  last  block 


The  PROTECTION  word  is    currently  unused.      At   a  future   date 
it  will  "be   used  to   allow  users   limited  access   to  each,  other's   files. 
A  file  name   is  placed  in  the   directory  as   follows: 

1.  A  hash-coding  is  performed  on  the  6   character  name   and 

USERID,  mapping  it  into  the   range    (0,17To). 

2.  A  6k  word  (8  entry)  block   of  the   directory  whose  number 
is   obtained  from  (l)    is   read  into   core    (the   access 
routines    check  to  see   if  that  block  is    already  in   core 
to   avoid  re-reading). 

3.  A  sequential  search  is   started  at  the  beginning  of  the 
block  for  a  free  entry    (BIT  0   of  the   TYPE  equal  to   0). 

The  next   sequential  blocks    are   read  into   core   if  necessary, 
k.      An  entry  is   made,    and  the  block  is   rewritten  onto  the   disk, 
An  entry  is    found  in   a  fashion   similar  to  insertion,   except 
that   searching  stops  when: 

1.  The    correct  name   is   located,   or 

2.  An  entry  that  has  never  been  used  (i.e.,   BIT  1   of  TYPE 
equals   0)    is   found. 

The   reason  for   criterion    (2)    is  best   illustrated  by   an  example, 
Assume   that  names   A,   B,    and  C   all  map   into  block  N  that  has  never  been 
used,    and  are   inserted  in  the   above   order.      File  B  is   then   deleted.      The 
search   for  file   C  should  not    give   up   at   the   first   free   entry    (i.e.,   that 
formerly   occupied  by  B) ,  but  should  continue   until  an  entry  is   reached 
that  has   never  been   used.      This   guarantees   that   searches   never  terminate 
prematurely. 


The  directory  has  room  for  102U  entries.   Current  estimates 
are  that  not  more  than  half  of  the  directory  will  ever  be  in  use  which 
implies  that  the  hashing  technique  will  rarely  have  to  access  more 
than  one  block. 
B.   File  Storage  and  Allocation 

The  bulk  of  the  disk  is  dedicated  to  actual  file  storage. 
This  area  of  the  disk  is  divided  into  blocks  of  128  words  each.   A 
file  is  a  linked  string  of  blocks,  and  has  the  following  structure: 


FIRST 

0            126     127 

0            126    127 

0            126    127 

0    L-l    L       127 

BLOCK 

DATA         |     • 

-*|  DAI  A                •    ■■ 

»■    DAI  A               •  " 

"""*    DAI  A    UiMUoIijJJ    1 

NUMBER 

(L  =   LENGTH) 


Figure    3.      File   Structure 


All  blocks   except  the   last   contain   127  words   of  data,    followed 
by   a  one  word  link  pointing  to  the  next  block.      The   last  block  in  the 
file,   which  may  also  be   the   only  block,    contains   anywhere   from  2   to   128 
words  without  a  link.      The   reason  that   a  last  block  never  contains   one 
word  is   that  the  previous  block  may  be  made   into  the   last  block  of  length 
128  words,   thereby  including  the   one  word. 

A  file's  position  on  the   disk  is   fully   described  by: 

1.  The   first  block  number  of  the   file. 

2.  The  number  of  full  blocks    (i.e.,  blocks  with   links). 

3.  The  number  of  words   in  the   last  block. 

The  disk  contains  6lUU  words  per  physical  track,  or  exactly 
k8  blocks  of  128  words.  Since  the  disk  is  fixed  head,  blocks  M  and  N 
are   equivalent  with  respect  to  head  position  if    M  =  N,   mod  U8.      One  block 
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takes   approximately   820  usee,   to  pass   under  the  heads.      It   can  be   seen 
that  if  two  successive  blocks   in  a  fiie>  M  and  N,   are   related  such  that 

(1)  N  -  M+2,   mod  U8 

then  the   software  has   approximately  820  usee,    from  the  time  block  M 
is   transferred  before  block  N  is   in   a  position  to  be   read  or  written. 
Software   response  time   for  initiating  a  transfer  is    considerably  less 
than  this,   so   if  all  blocks   in  a  file   satisfy  the   above   relationship, 
a  file    can  be   read  or  written  at  the   rate   of  2k  blocks   every  revolution. 
The  total  transfer  time   T   for  a  file   of  L  blocks,   including   an   average 
half-revolution   latency  of  l6.7  ms.    is 

(2)  T  =   16.7  +  1.62L  ms. 

The  block  allocation  scheme  must  therefore  allocate  block 
numbers  that  satisfy  (l)  in  order  to  achieve  this  reduced  transfer  time. 
This  is  achieved  by  maintaining  two  lists  of  unused  blocks  on  the  disk. 
One  list  contains  the  block  numbers  in  sorted  order  (i.e.,  successive 
blocks  differ  by  2,  mod  k8   where  possible),  while  the  other  list  contains 
unsorted  block  numbers.   Blocks  are  allocated  from  the  first  list,  and 
deallocated  into  the  second  list.   When  the  list  of  sorted  blocks  is 
exhausted,  the  unsorted  list  is  sorted  out,  emptied,  and  transferred 
back  into  the  first  list. 

To  minimize  accessing  the  disk  for  free  block  numbers,  a  copy 
of  the  top  6k   words  of  the  sorted  list  is  kept  in  memory.   Blocks  are 
allocated  from  here  until  the  list  is  emptied,  at  which  point  it  is 
refilled  from  the  disk.   The  disk  layout  is  shown  in  Figure  k. 
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ADD  FREED  BLOCKS  HERE 


UNSQRTED.  LIST 

SORTED  LIST 

, ■■ 

!-*•  OBTAIN  NEW  BLOCKS  FROM  HERE 
Figure  h.      Free  Block  Lists 
Sorting  of  free  blocks  takes  place  infrequently  as  there 
are  1359  blocks  available  (block  0  is  not  used) .   Sorting  is  done  by 
the  following  algorithm: 

1.  An  IR  program  segment  for  sorting  is  loaded  into 
3i+000Q  by  DSKGET. 

2.  Banks  0  and  1  are  saved  by  BNKSWP. 

3.  The  unsorted  list  is  read  into  bank  0. 

h.      The  block  numbers  are  sorted  into  one  of  hQ   slots 

in  bank  1  where  block  N  is  placed  into  slot  N,  mod  kQ. 

5.  A  scan  is  made  of  the  slots  starting  at  slot  0.   A 
block  number  is  removed  and  placed  back  into  a  list  in 
bank  0.   The  scan  examines  every  other  slot  and  keeps 
removing  blocks.   If  a  slot  is  empty,  the  next  sequential 
slot  is  examined.   Note  that  slot  0  follows  slot  hf . 

6.  Scanning  stops  when  all  slots  are  empty. 

7.  The  free  block  lists  are  restored  to  the  disk. 

8.  Banks  0  and  1  and  the  program  segment  are  restored. 

This  procedure  takes  about  0.5  seconds,  and  guarantees  that  where  possible, 
successive  blocks  differ  by  S,  mod  U8  where  S  is  >_  2  and  minimal. 

Flowcharts  for  the  main  IR  functions  are  shown  in  Figures  5-9. 
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Figure  5.   IRREQ  Flow  Diagram 
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RETURN 
CODE  =  1 
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Figure  6.   Read  and  Save  Flow  Diagrams 
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Figure  7.   Delete  Flow  Diagram 
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Figure  8.   Write  Flow  Diagram  (Part  l) 
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SEND  TO  360 
OVERLAY=YES 
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OVERLAY=NO 
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Figure  9.   Write  Flow  Diagram  (Part  2) 
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APPENDIX  A 
IR  INTERNAL  ROUTINES 
This  appendix  contains  excerpts  from  the  IR  system  that 
define  the  names  and  calling  sequences  of  most  of  the  internal  routines 
It  should  prove  helpful  if  it  is  ever  necessary  to  expand  the  system. 
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GODISK 

Performs   a  disk  transfer  using  locations   defined  in 
page   0   of  bank   3. 

BNKSWP 

TRANSFERS  WORDS  1+-17777 

CALLING  SEQUENCE: 

TAD  (BLK+DIR    /0=WRITE,  U000=READ 

JMS  BNKSWP 

(RETURN) 

BLOCK  NUMBERS  ARE:        0,  2,  U,  6,  10,  12,  lU,  l6 

USES  DISK  WORDS  DKC1  to  DKC1+177777 

DSKGET 

READS  AND  WRITES  PROGRAM  SEGMENTS  AT  3^000-35777 

CALLING  SEQUENCE: 

TAD  (BLK+DIR    /BLK<U0(8) 

JMS  DSKGET 

(RETURN) 

USES  DISK  WORDS  DKC2  TO  DKC2+77777 
BLKIO 


READS  AND  WRITES  STANDARD  LIBRARY  BLOCKS 

FORMAT: 

WORDS  1-177:     DATA 

WORD  200:       LINK  TO  NEXT  BLOCK 

THE  LAST  BLOCK  OF  A  FILE  CONTAINS  FROM 
1  TO  200  DATA  WORDS,  AND  NO  LINK  WORD 
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CALLING  SEQUENCE: 


JMS  BLKEO 

FUNC 

BLOCK 

MEMADD 

LINK/LENGTH 

(RETURN) 


/BLOCK  NUMBER 

/LOCATION  OP  DATA 

/CONTAINS  LENGTH  IF  LAST  BLOCK 


THE  LINK/LENGTH  WORD  IS  0  FOR  200  WORDS  IN 
THE  LAST  BLOCK 

THE  LINK/LENGTH  WORD  IS  SET  TO  0  WHEN  THE 
LAST  BLOCK  IS  TRANSFERRED 


FUNC: 


BIT  0: 
BIT  1: 
BITS  6-8: 


1  FOR  READ,  0  FOR  WRITE 
1  IF  THIS  IS  LAST  BLOCK 
FIELD  FOR  DATA 


READF 

READ  A  LINKED  FILE  FROM  THE  DISK 

CALLING  SEQUENCE: 


JMS  READF 

BLOCK 

/FIRST  BLOCK  NUMBER 

NBLOCKS 

/NUMBER  OF  FULL  BLOCKS 

LENGTH 

/LENGTH  OF  LAST 

MEMADD 

/LOC  OF  DATA 

BANK 

/FIELD  IN  BITS  6-8 

WRITF 

WRITE  A  LINKED  FILE 


CALLING  SEQUENCE: 

JMS  WRITF 

BLKLST 

NBLOCKS 

LENGTH 

MEMADD 

BANK 

(RETURN) 


/NUMBER  OF  FULL  BLOCKS 
/LENGTH  OF  LAST 
/LOC  OF  DATA 
/FIELD  FOR  DATA 


BLKLST  POINTS  TO  A  BANK  3  LIST 
OF  BLOCKS  TO  BE  USED 
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GETBLK 

GETS  A  POINTER  TO  A  LIST  OF  SORTED  BLOCKS 

CALLING  SEQUENCE: 

TAD  N  /NUMBER  OF  BLOCKS  NEEDED 

JMS  GETBLK 

(RETURN)        /AC  CONTAINS  POINTER  TO  LIST 

FREBLK 


FREE  A  LIST  OF  BLOCKS  BY  WRITING  THEIR  NUMBERS 
ONTO  THE  DISK 


CALLING  SEQUENCE: 

TAD  N 

JMS  FREBLK 

BBUF 

(RETURN) 


/NUMBER  OF  BLOCKS 
/LOCATION  OF  LIST 


DIRlO 


READ  AND  WRITE  DIRECTORY  BLOCKS 


CALLING  SEQUENCE: 

TAD  (N+DIR 
JMS  DIRIO 
(RETURN) 


/N  BETWEEN  0   and  177 
/DIR=UOOO   FOR  READ 
/BLOCK  IS   IN   DIRBUF 


DIRNXT 


GETS  POINTER  TO  NEXT  DIRECTORY  ENTRY 


CALLING  SEQUENCE: 


TAD  N 

JMS  DIRNXT 

( RETURN ) 


/AC  HAS  POINTER 


IF  N  IS  BETWEEN  0  AND  177,  THAT  BLOCK  IS  READ, 

AND  THE  POINTER  IS  AT  ITS  BEGINNING. 

IF  N  IS  NEC,  THE  NEXT  SEQUENTIAL  ENTRY  IS  OBTAINED 
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DIRSRC 

SEARCHES  FOR  NAME  IN  PARAMETER  LIST 

CALLING  SEQUENCE: 


JMS  DIRSRC 
(RETURN) 


/AC  CONTAINS  POINTER  IF  FOUND, 
/ELSE  0 


DIREMP 

FIND  AN  EMPTY  SLOT 

CALLING  SEQUENCE: 

JMS  DIREMP 
(RETURN) 


/AC  HAS  POINTER 


SAVE 


SAVES  A  FILE  ON  THE  DISK  IF  FUNC  BIT  2=0 

IF  DIRPNT=0,  GETS  NAME,  ETC.  FROM  PARAMETER  AREA, 
IF  DIRPNT  IS  NON-0,  THEN  USES  THAT  DIRECTORY  ENTRY. 


GETLEN 

COMPUTE  DISK  PARAMETERS  FROM  CORE  LENGTH 

CALLING  SEQUENCE: 


TAD  LENGTH 
JMS  GETLEN 
LENGTH 
NBLOCKS 
( RETURN ) 


/NUMBER  OF  WORDS 

/LENGTH  OF  LAST  HERE 
/#  OF  FULL  BLOCKS  HERE 


COMLEN 

COMPUTE  CORE  LENGTH  OF  A  FILE 

CALLING  SEQUENCE: 

TAD  LEN         /PACKED  DIRECTORY  FORMAT 

JMS  COMLEN 

(RETURN)        /LENGTH  IN  AC 
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APPENDIX  B 
DISK  STORAGE  ALLOCATION 


2k 

The   IR  system  is    implemented  using  the  Data  Disk  that   is 
currently  attached  to  the  PDJP-8.      A  new  interface   is    currently  being 
developed  for  the   disk,    and  will  have  the   following  characteristics: 

1.  A  total   capacity  of  29^,912  l6-bit  words    (12  bits   data, 
1  bit  parity,   1  mark  bit,   2  timing  bits). 

2.  Bi-directional   capability  of  from  1  to  8192  words 
per  transfer. 

3.  The   ability  to  begin   and  end  a  transfer  to   any  point 
on  the    disk. 

k.      Transfer  speed  of  5.H  ysec.   per  word. 
5.      Rotational  speed  of  30  revolutions  per  second. 
The   IR  system  logically   divides   the   disk  into   six  areas    as 
follows    (see   Figure  B-l): 

1.  IPL  tracks   -  12,288  words   reserved  for  the   system 
bootstrap,    restart  programs,   etc.      This    area  is   not   used 
by   IR  since   it  is  write -protected. 

2.  Core   swapping  -  65,536  words    are   set   aside    for  the 
purpose   of  saving  core   images    containing  data  structures 
and  display   files   associated  with  each  of  eight    consoles. 
There   is   enough   room  for  sixteen  banks   of  core,    allowing 
each   console  to   save  two  banks   of  core.      GLASP   accesses 
this    area  via  BNKSWP  which  is  provided  by  IR. 

3.  Program  segments   -   GLASP  may  retrieve   any  of   32   "programs," 
each  of  length   102*+  words,    from  this    area  by   calling  DSKGET, 
The   total  storage   allocated  here   is    32,768  words. 
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k.      Free  block  lists   -  20U8  words    are   set   aside   to   store 
the   sorted  and  unsorted  lists   of  free  blocks. 

5.  Directory  -  this   area  of   8192  words   is  used  to  store 
the   library  directory.      Since  each  entry  uses   8  words, 
there   is   room  for  102*+  entries. 

6.  Library  storage   -  the   remainder  of  the   disk  is    divided 
into  1360   128-word  blocks   for  a  total  of  17^,080  words. 
These  blocks   are   used  for  actual   data  and  picture   storage, 


0 

IPL 

12,288 

1 

CORE  SWAPPING 

TT,82U 

PROGRAM  SEGMENTS 

108,592 

FREE  BLOCK  LISTS 

110.6U0  ' 

DIRECTORY 

118,832 

LIBRARY  STORAGE 

292,912 

Figure  B-l.      Disk  Storage  Map 
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APPENDIX  C 
DISK  MONITOR  SYSTEM 
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Until  recently,   all  program  development   for  the  PDP-8  was 
done  either  on  the   Dectape  operating  system,   or  on   a  PDP-8  assembler 
that   ran  in  the   360.      The   former  suffered  from  excessively  long 
periods  needed  for  file-editing,   assembly,   and  listing  because   of 
the   slow  tape   units,  while  the   latter  system  was    considered  close  to 
useless    due  to  excessive   turn-around  time.      The   acquisition   of  a  disk 
and  a  high  speed  printer   (Teletype   Corporation's    Inktronic  printer — 
120   characters  per  second)    for  the  PDP-8  advised  development   of  a  local 
disk-based  monitor  system.      Rather  than   start   from  scratch,   it  was 
decided  to   adapt  DEC's   Disk  Monitor  System  to  run  in  the   Digital  Computer 
Laboratory  environment.      This   involved  modifying  DEC's  programs,    and 
writing  some  new  ones   to  match  the    current  hardware   configuration. 

Before   reading  the   following  sections,   the   reader  is   strongly 
advised  to   familiarize  himself  with  DEC's   manual  "Disk  Monitor  System," 
DEC  -08-SDAB-D  which   describes   most   of  the  DMS.      The  material   contained 
below  is   intended  to  be   a  user's   guide  to  the  modified  system. 
Generating   a  User  SWAPTAPE 

Each  user  must  have   a  SWAPTAPE    (physically   a  DECTAPE)    on 
which   to   store  permanent   copies   of  his   files   and  programs.      A  SWAPTAPE 
is    generated  by: 

1.  Bringing  up   any  SWAPTAPE  on   unit    #8. 

2.  Mounting  an   unused  (but   formatted)   tape   on  unit    #h. 

3.  Calling  program  SYSGEN.* 


*     Throughout   this    appendix,   programs   that   run  under  the   DECTAPE  system 
are   referred  to   as    "PROG,"  while   DMS  programs   are   referred  to   as 
".PROG."      The  _^  is  typed  by  the   DMS,   not  by  the   user. 
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The  tape   on   unit   #h  is  now  a  complete    copy  of  the   one 
on   unit   #8. 

The   format   of  a  SWAPTAPE  is   shown  in  Figure   C-l. 

0  377         400    i+01         402  2601 


Standard  Dectape 
Operating  System 


Monitor 
Head 


Image   of  disk  blocks 
0-2177  in  that   order 


Figure   C-l.      SWAPTAPE  Format    (Block  Numbers) 

Loading  the   DMS 

The   DMS  is   transferred  from  SWAPTAPE  to   disk,    and  given 
control  by: 

1.  Bringing  up  the   SWAPTAPE   on  unit    #8. 

2.  Calling  SWAP. 

The   DMS   responds  with   a  j_.      The   user  may  now   call  up   any 
DMS  programs  by  typing  the   appropriate  name,    as   is    described  in 
DEC's  publication. 
Modifications  to   DEC's   DMS 

1.  The   DMS  monitor  head  was    replaced  with   one   appropriate 
to  the   Data  Disk  on  the  machine.      All   characteristics 
are   the   same  except  that: 

a.  The  monitor  head  uses    7^+00-7777  in   bank   3  in 
addition  to   7600-7777  in  bank   0. 

b.  SYSI0  may  be    called  from  any  field   (the   DF  points 
to  the    caller) . 

2.  .CD.    is   modified  so  that   Dn:FILE  refers   to   a  file   on 
a  SWAPTAPE  on   unit   #n.      CDIO    is  modified  similarly. 
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3.       .PIP  -  all  functions   work  with  Dn;    taken   as   above, 

except   that   copy  functions  may  NOT  involve   a  SWAPTAPE. 
h.      .PALD  -  extra  symbols   are  kept   in  bank   3  instead  of 

.SYM,    and  OPT-R  results  in  paginated  output  on  the   Inktronic, 
New  DMS  Programs 

The   following  are  new  programs    developed  for  the  DMS,    along 
with   a  description   and  operating  instructions: 

1.  .LIST  -  lists   a  single  ASCII   file   in  paginated  form. 
OPT-T  sends   listings   to  the  ASR-33,    anything  else   uses 
the   Inktronic. 

2.  .INDX  -  similar  to  L  option   in    .PIP  except  that   it   is 
automatic   and  uses   the   Inktronic. 

3.  .COPY  -  used  to   copy  ASCII   files  between  Disk,   SWAPTAPE, 
and  DECTAPE.      Disk  files    are   designated  as   S:FILE, 
SWAPTAPE  files    as   Dn:FILE.      If   a  carriage   return  is   typed 
in   response   to   *OUT:    or  *IN:    or  both,   the   DECTAPE  I/O 
routines   are  brought   in  from  a  DECTAPE   on  unit   #8  and 
will  type   OUTPUT:    or  INPUT:    or  both   for  the  missing  files. 
Disk  or  SWAPTAPE  files    are   terminated  by   a  double    form- 
feed  (automatically  placed  by  the   DMS),  while   DECTAPE  files 
must   contain   $_  in   column   1  to  properly  terminate. 

h.      .VGET  -  loads  programs   from  DECTAPE  into   core,    and  returns 
to  the   DMS.      Light-pen  the  program  desired. 

5.  .RCVR  -  returns   control  to  DECTAPE  system. 

6.  .VRFY  -  verifies   that  no  errors   exist  in  the   user's   files 
by  checking  all  links. 
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Saving  the   Disk  on   a  SWAPTAPE 

To  save   the   contents   of  the  user's   disk  on  his   SWAPTAPE: 

1.  Mount   the   tape   on  unit   #k . 

2.  Call    .EXIT. 
Control  is   returned  to  the   DMS. 
IPL 

The  first  two  tracks  of  the  disk  have  a  special  write -protect 
feature  and  are  used  for  Initial  Program  Loading.  The  DMS  Monitor  Head 
is  normally  resident  there,  "but   it    can  be   restored  by: 

1.  Turning  off  the   IPL  Write-Lock. 

2.  Running  WIPL. 

3.  Turning  the  Write-Lock  back  on. 

The  Monitor  Head  may  be   read  into   core  by  running  program 
IPL  or  by: 

1.  Loading  6557  into  location   7776. 

2.  Loading  5377  into  location   7777- 

3.  Starting  the    computer  at   location   7776. 
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